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alternatives arc and their differences and similarities. 

Tim tangible components of a development environ- 
ment arc loan, software wMrlt i*jh be used in perform- 
ing the development activities delineated above. Tools 
may be genera) ones which support a variety of activ- 
ities, but more usually they have a purpose falling 
within one of the activities distinguished in this dis- 
cuss ion. 

The intangible components are the development pro- 
ordurea , prinaipln a anti practicaa which development 
practitioners are encouraged or required to use. There 
is an obvious, close interrelationship between these 
methodological components of the environment and the 
too) components - the procedures, practices and prin- 
ciples included in the development environment shape 
the function and nature of the tools and the tools, 
themselves, give concrete meaning to the methodological 
rules and guidelines. The tangible and intangible as- 
pects of a development environment must, therefore, be 
defined concurrently - proscribing either in isolation 
runs the risk of defining an infeasible nr ineffective 
environment. 

The core of a development environment is the net of 
provided for describing the characteristics, 
properties and functioning of a system during its de- 
velopment, These languages provide the media for com- 
munication, the basis for defining assessment tech- 
niques, and the means by which the relationships among 
alternatives may be explicitly or implicitly defined. 
Further, the languages allow the precise definition of 
the development environment's tool and methodological 
components in terms of how descriptions in the languages 
are prepared, modified, related and analyzed. 

A broad spectrum of development environments is 
possible, depending upon the number and variety of lan- 
guages and the extent to which a single development 
methodology guides the definition of the environment, 

At one end of this spectrum are toolbox ? a which provide 
a relatively large number of languages, generally hav- 
ing no well-defined interrelationships , and which sup- 
port a variety of development methodologies. The tools 
included in a toolbox are either general ones, useable 
upon descriptions in any of the languages and therefore 
ignorant of the specific details of any particular lan- 
guage, or specific ones strongly Hnke, to one partic- 
ular language and usable only with descriptions in that 
language. The tools are also generally independent so 
that they may be employed in a vaiety of combinations 
in support of the variety of methodologies for which 
the toolbox can be used, 

At the other extreme in the spectrum are develop- 
ment a tf a cam, These "union shops" of the development 
environment world provide a single, obviously very 
general, language and provide support for only a single 
methodology - practi tioners who do not know (or like) 
the language or who do not subscribe to the enforced 
methodology cannot obtain help from this type of 
envi ronment. 

it should be obvious that the ideal development 
environment lies somewhere between these two extremes. 
These development support .insComa should provide a 
coordinated set of languages having well-defined rela- 
tionships and features which allow the easy and natural 
expression of the properties, characteristics and func- 
tions of interest. This implies that development sup- 
port systems generally cannot be universal and, rather, 
are oriented toward the development of a specific class 
of systems. Further, the tools provided by a develop- 
ment support system should be interdependent, integrated 
around a collection of methodologies which are similar 


in nature but which accommodate a number of development 
styles. The "happy medium" to be struck Is one which 
encourages (and rewards!) good rractues but does not 
stifle individuality, The characteristics of these 
ideal development environments will be discussed further 
in the last two sections. 


PROGRAM CONSTRUCT I0H TOOLBOXES 

Current-day software system development environ- 
ments are, for the most part, of the toolbox variety and 
tend to support implementation activities occurring dur- 
ing the development of relatively simple systems. These 
ptvgrtsn construction environments provide tools to aid 
in the development of an executable description of the 
program and in the determination of the program's run- 
time behavior. They tend not to embody any particular 
development methodology. 

In order to suggest guidelines for producing de- 
velopment support systems, it is instructive to look at 
the components of current-day program construction en- 
vironments and take note of several trends evidenced by 
their history, The first of these topics is the subject 
of this section and the second is discussed in the next 
section. 

Our assessment of the current state of advancement 
in the preparation of program construction environments 
is oriented toward the facilities which the average 
development practitioner could expect (or could demand! ) 
to find as part of their computing facility, They are, 
therefore, those facilities which are well enough de- 
veloped to have been transferred out of "research" 
status - other facilities which are still under develop- 
ment are not discussed, It should also be emphasized 
that it is not necessarily feasible to implement all of 
the facilities indicated here on all computing systems 
and that their implementation on resource-impoverished 
computing systans is currently a research topic. 

The typical program construction environment makes 
available a plethora of programing languages, generally 
enough to satisfy any taste, style or proclivity, in 
addition to general-purpose, procedural languages, lan- 
uages are usually provided for specific problem domains 
e.g., Snobol), specific solution spaces (e.g., Lisp), 
or specific solution activities (e.g. , RPG), As is true 
of toolboxes in general, the languages are independent 
and no attempt has been made to define relationships 
among different languages. 

The vast majority of tools present in a program con- 
struction environment provide support for text prepara- 
tion activities. The task of translating a human-orient- 
ed, problem-oriented description into executable code Is 
well -understood and translators of significant sophisti- 
cation, in terms of t.ne language constructs they can 
successfully handle and the optimization they can per- 
form, are commonplace. Preprocessors, especially those 
providing structured-programming dialects of (generally 
older) languages lacking a reasonable set of execution 
control constructs, are also comnonplace. Finally, for 
those wishing to prepare a translator for a language of 
their own design, there are a variety of parser and 
lexical analyzer generator tools, 

Other, language-independent, text preparation tools 
are also available in current-day program construction 
environments. Chief among these are text editing sys- 
tems of which there is an extensive variety, The best 
appear to be ones which are character-oriented and CRT- 
based; but line-oriented editors seem preferable when 
only hard-copy terminals are available. Subroutine 
libraries also provide help in preparing the text of a 
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piwyram. 

Text retention tools are usually present at part of 
tlie general-purpose file system provided by the operat- 
ing system. Protection and access control facilities 
arc supportive of program construction; the latter, In 
particular, being valuable in the enforcement of develop- 
ment principles such as the principle of fnfonnation hid- 
ing [2], Retrieval facilities are typically file-orient- 
ed and, therefore, not very sophisticated with respect to 
composing a program out of units much smaller than a 
procedure. This failing can, however, be circumvented 
with facilities which allow the free composition of files 
by placing directives in one file indicating that all or 
part of another file is logically part of the file con- 
taining the directive, 

A variety of tools are typically provided to i ;j . con- 
sistency assessment. Simple tools of this type a r,- gen- 
erally built into the language translators and check for 
syntax errors, Semantic error detection tools are also 
frequently provided as part of translators. Seme of 
these check for simple errors such as a mismatch between 
arguments in a procedure invocation and the corresponding 
parameters. Others perform more sophisticated checks but 
require the users to give additional, semantic informa- 
tion so that the check can be carried out. For example, 
a units checker tool [3] has been developed for Pascal - 
it requires the specification of units, e.g., miles/hour, 
for program variables and then analyzes arithmetic ex- 
pressions to determine whether or not units cancel 
properly. 

Tools for checking the consistency between the pro- 
gram's overall dynamic ( i . e . , run-time) behavior and the 
program developer's expectations are primarily of the 
validation variety, This class of tools includes de- 
bugging support systems, path analyzers, testbeds, tost 
coverage analyzers, test data generators, etc. These 
cools a»’e typically language-specific. Also falling In 
this class are machine simulators which allow the execu- 
tion-style checkout of a program even though the machine 
on which it will eventually execute is not available. 

Other tools for checking a program's dynamic behav- 
ior by static verification techniques are not yet prev- 
alent, but are becoming more comnon. Most generally 
available are those, typified by DAVE [4,5], which check 
for properties which stem from semantic rules (such as 
definition of a variable's value prior to its first use), 
from rules of good practice (such as use of a variable 
be, ore redefinition of its value), or from general re- 
quirements pertaining to an entire class of systems 
(such as absence of deadlock), More sophisticated tools, 
typified by [6] and [7], use symbolic execution tech- 
niques and allow the checking of properties defined by 
the program developer and specific to the program itself. 

The remaining development activities of completeness 
assessment, structure exploration and binding exploration 
are generally not directly supported by any specific 
tools. Rather, there is a hodgepodge of tools which have 
been "collected" over the years that tend to allow de- 
velopers to investigate a program's completeness and ex- 
plore alternatives. Generally included in this collec- 
tion are cross-reference facilities, linkage editors, 
time-histogram facilities, etc. Specialized job control 
languages also provide support in carrying out these 
activities. Finally, additional support is sometimes 
provioed by homogenizing programning language interfaces 
so that multi-lingual programs can be constructed. 


TRENDS IN INF EVOLUTION OF 
PROGRAM CONSTRUCTION TOOLBOXES 

The hi story of the development of program construc- 
tion toolboxes exhibits some trends which, when extrap- 
olated, indicate what can be expected in the future. We 
do not propose that extending development in the direc- 
tions indicated by those trends will be sufficient to 
achieve truly effective development support systems. But 
the trends are indicative of an already established mo- 
mentum which provides a context for other evolutionary 
trends which we will propose, in a subsequent section, 
as additionally necessary, 

One trend that is quite obvious is toward interactive 
environments which provide the means for much quicker 
information transfer between developers and the computer, 
and vice versa, Once computer system users make the 
change from thinking of programs as a deck of cards to 
viewing their programs as text streams, interactive en- 
vironments greatly speed up the activities of program 
text preparation, entry and modification, In addition, 
such environments offer a basis for speeding up the 
other development activities of assessment or explora- 
tion. The overall benefit is that developers are freed, 
by the virtue of higher-quality "secretarial services," 
to devote a larger proportion of their time to more 
important, more intellectually challenging development 
tasks. Of course, this benefit comes at some cost, but 
this is generally not prohibitive and recognized as well 
worth it. 

Another trend is ini. •ration. With the development 
of sophisticated operating systems to serve as vehicles 
for the delivery of tools to development practitioners, 
there has been a tendency to provide a conmon Interface 
to the various facilities provided within and under the 
operating system. Another aspect of integration has been 
provision of facilities which allow the various tools to 
bo conveniently used in the combinations required under 
a number of development approaches and styles. 

Closely related is a trend toward verification. An 
example is the development of debugging facilities which 
are oriented toward high-level rather than assembly-level 
languages; for example, the development of the debugging 
subsystem for the Algoi-W language [8], It is important 
to note that this trend toward unification generally im- 
plies a narrowing of scope of attention to a smaller num- 
ber of languages, found by use over a number of years to 
be valuable, natural and sufficient for the representa- 
tion of programs. 

Closely related to these two trends is one which can 
be characterized as centralization, The tendency has 
been to provide new tools as part of a translator, per- 
haps optionally invokable, The usual, overriding reason 
for this is that the tool needs the facilities provided 
by the parser component of the translator and the (wise) 
decision is made to embed the tool in the translator 
rather than duplicate the parser, It should be noted, 
however, that when new language constructs are Involved, 
the too) is frequently provided as a stand-alone facil- 
ity; for example, structured programming preprocessors 
are the norm. However, the desire to make the tool in- 
dependent of existing translators sometimes adversely 
affects the new language constructs, 

Another trend, critical to providing program con- 
struction environments of any reasonable quality and 
effectiveness, has been toward program animation to pro- 
vide he 1 p for the activities of’ assessment and explora- 
tion. Because of the availability of the machine on 
which the program will run (or a simulation of the 
machine), there is a strong temptation to use execution 
to gain an understanding of a program's dynamic behavior. 
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further, this "easy way" *s encouraged because of the 
trend to centralize tools into a single programing .sys- 
tem - it is frequently impossible, for example, to have 
the syntax of a program checked without also executing 
the program or at least having an executable translation 
of the source text prepared, There is increasing recog- 
nition, however, that the inference of a program's dy- 
namic properties by execution is generally neither cost- 
effective nor effective, 

The final trend to be conniented on here concerns the 
environment's languages rather than its tools and can be 
described as a trend toward highav-quiility rcrfcitcntation, 
One aspect is a move toward increasing the understand- 
ability of programs. Founded upon a recognition that 
allowing an arbitrary relationship between the physical 
structure of a program and its logical flow (i.e,, the 
paths of execution through it) unnecessarily increases 
the complexity of a program, and fostered by the desire 
to automatically verify a program's correctness, there 
has been both a general recognition that a programming 
language must provide a rich set of simple, powerful and 
easily understood execution control constructs and an 
increasing tendency in the definition of new languages 
to provide such a set, 

Another aspect of understandability enhancement has 
been a move toward a separation of concerns. One simple 
example, evidenced by the Gypsy language [9] among others, 
has been the provision of constructs to explicitly con- 
trol the scope of variables rather than have the block 
structure of the program indicate its resource require* 
moots e:d the scope of variables. A more sophisticated 
example is provided by the constructs present in the Ada 
language [10] which allow a subprogram's intent (i.e,, 
its specification) to bo stated separately and redun- 
dantly of its implementation. 

A closely related aspect is the tendency to intro- 
duce, into a language's definition, rules of usage that 
are relatively easily checked and which foster the pro- 
duction of "correct" programs. The thought behind this 
tendency is that a program's function is more easily 
understood, and more easily checked for validity, if 
aspects of its operation (and sometimes its behavior) 
are stated redundantly In all of those places where they 
are of interest. Constructs for explicit control of var- 
ibje scope are an example, as are those for specifying 
the types of variables, it should be noted that facil- 
ities for redundant specification are usually accompanied 
by rules, enforced by the language's translator, requir- 
ing that the redundant specification be made by the lan- 
guage's users. This reflects the fact that these facil- 
ities stem from a realization that their use typically 
leads to "more correct" programs and that their imposi- 
tion can speed the development of programs which func- 
tion correctly, 

Another closely related aspect is the trend in lan- 
guage and translator design to provide facilities sup- 
porting modularity, typified by incremental compilation 
facilities, These facilities are usually coincident 
with procedure definition facilities which means they 
are not always sufficient, But they do tend to facil- 
itate incremental program development . 


INADEQUACIES OF 

PROGRAM CONSTRUCTION TOOLBOXES 

The general trend in the evolution of program con- 
struction toolboxes has been to provide facilities for 
hastening the development of appropriately functioning 
programs, Part of this has been the preparation of cre- 
ation activity facilities which free development prac- 
titioners from devoting an inordinate amount of their 


efforts to tne preparation and maintenance of the text 
of their program descriptions. Another part has been 
the introduction into programing languages of constructs 
fostering the development of correct, understandable pro- 
grams. The final part c f this trend has been the de- 
velopment of facilities for the consistency assessment 
of programs. 

An obvious inadequacy is the lack of facilities pro- 
viding direet, high-quality aid for completeness assess- 
ment and exploration activities. The problems associat- 
ed with these activities have been somewhat less impor- 
tant and attention has been justifiably directed toward 
the more important problems associated with creation and 
consistency assessment activities. But it is also true 
that these problems have been intellectually managable 
for the vast majority of programs developed, and It is 
only with respect to the development of large-scale, 
complex programs (i,c., aoftMra ayatana) that these 
problems become unmanagable and aid is required, 

When attention is turned to software systems as 
opposed to programs, several other inadequacies become 
apparent, These inadequacies primarily stem from a 
failure to take into account the special nature of sy,- 
tems that make them quite different from ordinary pro- 
grams. Systems are a conglomeration of interacting 
parts; sometimes this decomposition of a whole into 
parts is a natural phenomenon and sometimes it is artifi- 
cially Induced because of our inability to otherwise 
cope with the system's complexity. Thus, all activities 
concerned with developing a system must consider the sys- 
tem's parts emf their interactions and it is facilities 
for direct consideration of interactions that are absent 
from current-day program construction environments. 

More specifically, what Is missing are facilities to 
perform modelling. What is needed is the ability to 
focus upon the interactions, either as a prelude to de- 
veloping parts which support these interactions or in an 
attempt to assess the interactions of already developed 
parts, This requires the ability to abstract the func- 
tional, operational characteristics of the parts, i.e., 
the ability to prepare models of a part's interface and 
functional i ty . 

Spine modelling capabilities are Inherent in a pro- 
gram construction environment, It is possible, for ex- 
ample, to develop a system prototype, a simplified ver- 
sion which does not exhibit all of the properties of the 
eventual system but can be used in order to gain an 
understanding of systems of the type being developed. 

Use of models of this type can be called evolutionary 
programming [11] and can provide a very effective de- 
velopment method as evidenced by the MTS operating sys- 
tem [12] which was developed as a succession of progres- 
sively more elaborate "models," But it is equally impor- 
tant to be able to prepare horizontal models which rep- 
resent the entire system but only to a level of detail 
which is somewhat short of an executable version of the 
system. These types of models are of particular impor- 
tance during the early stages of development, by what- 
ever development method is being employed, when the task 
is to infer or specify overall system properties without 
the ability (or necessity) of executing the system to de- 
termine its properties. 

This leads to another inadequacy of current program 
construction environments, being the strong orientation 
toward functional i ty properties. During software system 
development, particularly when there are no previously 
developed, similar systems to provide hints concerning 
the system's eventual properties, practitioners need the 
capability to obtain estimates of the system's economics 
and performance, While this can be accomplished by im- 
plementing the system and gathering statistics during its 
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operation, this would be a regression to an ancient 
practice, described by Graham [13] as building systems 
like the Wright brothers built airplanes - constructing 
them, pushing them off a cliff, watching them crash ami 
starting all over agian. 

Another inadequacy has been implicit in the discus- 
sion so far • the inadequate recognition of pre-imple- 
mentation development stages. During these stages, it 
is critically important to be able to unambiguously re- 
cord and rigorously assess the policies and strategics 
governing the system rather than the mechanisms ami al- 
gorithms used in its implementation. The languages pro- 
vided are inadequate for expressing these attributes of 
a system and the tools provided do not support investi- 
gation of the system's properties as derived from these 
attributes, Further, the languages and tools are not as 
helpful as necessary or desirable during the post-imple- 
mentation stages of maintenance and modification, which 
are more akin to pre-implementation stages than they are 
to implementation itself. 

The final inadequacy to be noted here is in essence 
a secondary effect of the strong orientation toward the 
implementation stage of development. Witli respect to 
software systems, the development of software 
is no longer a personal thing between one person and the 
computer * there is, instead, a development team (some- 
times more appropriately misspelled "teem"), as well as 
project managers , customers, users, acceptance testers, 
documentors , user-guide wri ters , etc. Each of these 
persons has differing desc: *ptiona1 requirements and 
this severely complicates the problems of communication 
and highlights the fact that prograntning languages and 
programing language oriented tools arc not sufficient 
for an effective development support system, 


PRINCIPLES GUIDING FUTURE EVOLUTION 

We do not propose "starting all over again" in order 
to prepare effective development support systems, First, 
evolution, as opposed to revolution, is too well recog- 
nised as an efficient and successful paradigm. Second, 
revolution is not warranted, at this point, since program 
construction environments are basically on the right 
track and their inadequacies stem primarily from consid- 
eration of too small a set of concerns. Third, wc fee! 
that the trends evident in the evolution of program con- 
struction environments are, with only two exceptions, en- 
tirely appropriate and conducive to the eventual emer- 
gence of development support systems. 

Therefore, in this section, we present several prin- 
ciples which we feel have affected the evolution of de- 
velopment environments only secondarily or not at all, 
tut which must be given strong emphasis in order that 
the evolutionary process yields effective development 
support systems and that the emergence of such systems, 
and their delivery to working practitioners, is both 
quick and timely. 


Principle !: Snkance the expreenive power and rie/inean 

of the languages w»w -riving t ho devotop- 
rr.cn t environment. 

The need to describe characteristics in addition to 
functionality and operation and the need to communicate 
essential information to a variety of audiences means 
that languages are needed to directly support a Multi- 
plicity of views of the system being developed. The 
traditional dual views of data flow and control flow are 
a simple illustration of what is needed - description 
capabilites providing alternative views and having a 


formal (although not necessarily algorithmically ana- 
lyzable) relationship. Perhaps the ideal would be to 
have a single representational technique, not necessar- 
ily diructly used by developers, from which all other 
system descriptions arc analytically derivable, Whether 
or not this is an ideal, and what the various descrip- 
tion techniques should be, will require a good deal of 
investigation, 

In addition to evolving a set of coordinated, formal- 
ly rclatable languages, it is important that none of the 
languages exhibit a rococo nature. Far example, the lan- 
guage which was developed as the bas J s of the DREAM de- 
sign support system [14] is somewhat of this nature, In 
trying to put into one language, ir consistent forms, 
all of the descriptional capabilities we felt necessary, 
we possibly created the PL/I of design description lan- 
guages, The lesson learned is that it is much better to 
define a multitude of languages, each having a well-de- 
fined purpose, than it is to define a single language 
having a multitude of purposes - this follows the ob- 
vious extension of the trend toward separation of con- 
cerns evidenced by recent developments in programming 
language design. 

Further, in the development of individual languages 
we should strive for a reasonable balance between suffi- 
ciency and naturalness, Having a parsimonious set of 
constructs is desirable because of the attendant clarity 
of the language and the relative ease with which one may 
obtain a formal basis for the language. Naturalness is 
obviously important but tends to increase the language's 
"size," In order to realize the aim of having formal 
relationships among the languages, it is perhaps best to 
err on the side of sufficiency. 

One last word of caution is that wq must be careful 
not to create a Tower of Babel situation as we cannot 
afford to forestall and inhibit progress by a "profusion 
of tongues." This analogy indicates that wo should be 
as concerned with the meta-languages we use to define 
the languages as we are with the languages themselves, 


Principle S; Pcvelop more extensive animation fad liters, 
in alone coordination uith the development 
of languages. 

The most challenging of development activities is 
assessment, taxing our inference capabilities to their 
utmost, particularly in the case of concurrent systems, 

We must, therefore, increase the facilities, whether they 
be simulation-based or analytic in nature, available for 
aiding the inference of a system's properties while it 
is under development and the estimation of the properties 
it will eventually exhibit when its development is com- 
plete . 

$o that we do not suffer decidability and computa- 
tional complexity problems, the animation tools should 
be of a feedback variety. By this, we mean that the 
tools should derive information for the developers con- 
cerning the system's dynamic properties, but should not 
attempt to completely cerffy that a system exhibiting 
these properties is appropriate, leaving that task for 
the developers to perform by interpreting the derived 
information, Animation tools of this sort have been de- 
veloped ([4, 5, 15) for example) and experience with their 
use indicates that while quality is a serious problem, 
they provide inmeasurable assistance by uncovering po- 
tentially erroneous situations which would have escaped 
detection under a less-rigorous inspection done without 
the tool's aid. 

That the development of ar .ation tools and of de- 
scription languages must be coordinated is obvious since 
each affects the form and content of the other. An 
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additional reason is that, for effective system develop- 
ment, the processes of synthesis and »vwJ yuis must bo 
tightly Interleaved so that assessment is a continuous 
activity, integrated with the activities of creation am) 
exploration - otherwise, we arc back with the Wright 
brothers again. 

Principle J.* dive concent i\ited attention to pivuidt’s? 

t i,oltt which directly asp lorn tton 

activities. 

On the surface, this principle means that support 
must be developed for preparing and exercising system 
models, both prototypes and horizontal abstraction mod- 
els, Additionally, however, differential elaboration 
of these models must be facilitated since it is in this 
way that alternatives for achieving some system part can 
be assessed within the context of the rest of the system, 
This assessment-in-context is critically important to 
any meaningful exploration of alternatives. 

To facilitate and enhance the exploration of alter- 
natives, it is also necessary to provide facilities for 
the aggregation and structuring of information concern- 
ing the system being developed, Underlying Oijkstra's 
development of the guarded conmand construct [16] was 
the important observation that the creation of a pro- 
gram is not an orderly process but is more generally a 
relatively random porcess in which computational details 
emerge in an order which does not correspond to the 
order in which they are performed during program execu- 
tion, This phenomenon is even more true of the pre- 
invlementation development stages and thus it is im- 
portant to provide an environment under which pieces of 
information can be recorded in the order of their gen- 
eration and structured into a coherent base of informa- 
tion from which developers can extract "chunks" com- 
posed of interrelated pieces of information, 

Even more sophisticated facilities are important for 
the support of exploration activities. First, the in- 
formation retention facilities must be able to distin- 
guish and keep track of versions of a system, prefer- 
ably with only straightforward, natural directives from 
the' developers as to the relationships among pieces of 
information concerning the system, Second, the facil- 
ities must allow the modification of the system descrip- 
tion within any relatively arbitrary "slice" through the 
information base, Finally, the facilities should ideal- 
ly monitor and gride the information agglomeration pro- 
cess, checking for inconsistencies and missing informa- 
tion - this capability obviously demands a significantly 
more extensive unde-standing of the development process 
than we currently possess, 


Principle it The process of natural selection should he 
facilitated nt every opportunity , 

This principle is obvious and should not need to be 
stated, but there is a frequent tendency to forget this 
basic tenet of evolution. It is useful, therefore, to 
point out some concerns relating to this principle which 
should be kept in mind, 

First, experimentation is an absolute necessity. 

This means, however, that much more is required than the 
conduct of experiments intended to investigate the effi- 
cacy and efficiency of various practices, principles and 
procedures - that is, various methodologies, it means 
that individual tools must be constructed with attention 
to providing mechanisms for monitoring their individual 
and collective use, It means that the operating system 
environments through which the tools are delivered to 


development practitioners must allow the monitoring of 
tool usage and the collection of statistics on tool 
utilization, finally, it means that an understanding 
must be developed of how to conduct the exp, -intents, 
what data to collect, hew to reduce the data to meaning- 
ful derived measurements, and how to use the results to 
guide future evolution and experimentation. 

To facilitate evolution, it is also necessary to 
have an organization underlying the development environ- 
ment which is conducive to the reorganization, extension 
and modification of the tools present in the environment. 
Users should be able to employ the tools in whatever 
sequence and ccmbi nation seen) warranted and productive 
given the intents of the tools, The tools themselves 
should be robust enough to function, at least to the 
level of reporting an error, in (perhaps bizarre) con- 
texts not originally envisioned. Users should also be 
able to modify the tools, particularizing them to spe- 
cific tasks. (This, however, raises some serious sup- 
port questions.) Finally, it should be possible to 
easily add new tools to the environment. 

To achieve this modifiability of the tools 
and their use, we feel that it is not appropriate to 
continue the trend toward centralization. In fact, it 
would be best, at this point, to unbundle the tools 
typically present in a programming system. The avail- 
ability of a stand-alone parser, for example, would 
facilitate the development of other stand-alone tools 
while reducing the effort needed to produce them. Inter- 
face problems arise, but we feel they are solvable and 
the benefit gained is well worth it. 

The .process of natural selection further requires a 
management environment which facilitates and enenurages 
the use of tools, in addition to sometimes well-founded 
suspicions as to the efficacy and efficiency of indi- 
vidual tools, practitioners also possess a "momentum" in 
the use of well-known practices and procedures which in- 
hibits their adoption of new tools,, Management should 
foster the surmounting of this inertia by indicating 
that the use of tools, even those without clearly estab- 
lished "credentials," is both expected and respected. 

This requires that management be willing to give the 
necessary monetary support to using and learning to use 
the tool. Management must also give monetary support to 
the task of toolsmi thing and establish this as a respect- 
able and desirable activity. 

Critical to establishing an environment in which 
natural selection can easily run its course is the de- 
velopment of criteria b 1 which tools may be judged. 

These criteria are necessary in the design of experiments, 
required so that practitioners can make intelligent 
choices of which tools to use and when, andalmost pre- 
requisite to management willingness to provide the neces- 
sary support and encouragement. However, waiting until 
these criteria are fully developed would Introduce a de- 
bilitating delay and it is necessary that some risks be 
taken and there be a willingness to develop and refine 
the criteria concurrent with the experimental use of tools . 


Principle 5: Encourage 4 but do not m-in-iitc, the use of 

development practice a, procedures and 
principles . 

At, this point in the evolution of development method- 
ologies, not enough is known as to their value in partic- 
ular development situations to warrant their strict im- 
position. Rather, their value must be explored simulta- 
neously with the exploration of criteria for tool usage 
and of tools themselves, In addition, we feel that it 
will never be appropriate to mandate the usage of a 
single set of principles, practices and procedures for 
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development because there will always be a wide variety 
of viable styles and a wide variance in practitioner 
sophistication and level of experience. 

It seems best, therefore, to head toward development 
environments which embody a development ,*/i £’o<u>[Jy rather 
than a strict methodology, which provide tools supporting 
a variety of styles consonant with the development phi- 
losophy, and which (perhaps subtly, perhaps blatantly) 
reward working within the guidelines of the philosophy. 


Principle Hi Hunan atvjiiutcving oonouiei'ationii $faulJ bo 
of pi’iinwy concern. 

An environment which fosters natural selection, en- 
courages experimentation and invites practi ticners to 
use tools in sopport of their development activities 
cannot exist without the tools being easy and convenient 
to use. There should be relatively homogeneous inter- 
faces to the individual tools. The tools should be 
oriented toward users who are unsophisticated with re- 
spect to computer science in order to foster their in- 
volvement in the development process, particularly dur- 
ing the prciinplcmcntation stages. The tools should pro- 
vide users with extensive control over its functions and 
facilities so that their usage may easily be tailored 
to the task being done and the users’ need. 

With respect to human engineering concerns, we feel 
that the trend toward interactive environments is not 
necessarily a good one to pursue. The activities of 
assessment and exploration seem to be primarily off-line 
activities and the development environment would, there- 
fore, seem best supported by remote- job-entry facilities 
coupled with high-speed, hard-copy output facilities. 

The exception would seem to be the use of interactive 
graphics devices, such as in the Tell system (17], to 
provide quick display of different system characteristics. 


CONCLUSION 

The transfer of technological developments from re- 
search status to use by "real-world" practitioners seems 
to fairly consistently require a ten-year period of time 
(IS], In this paper, wq have attempted to propose and 
justify some principles guiding the preparation of soft- 
ware development environments which are critically nec- 
essary to achieving, and hopefully speeding, this 
transfer rate, We first reviewed the state-of-the-art 
of development environments, noting their strong orien- 
tation toward the construction of relatively simple soft- 
ware systems, We then indicated some of the trends 
evidenced by the evolution of these program construction 
environments and some of their inadequacies. These ob- 
servations formed a basis for suggesting several prin- 
ciples (some at slight variance with previously estab- 
lished trends) to guide future evolution and arguing 
their criticality to achieving truly effective and effi- 
cient development support environments , 

Our observations have been primarily with respect to 
development practitioners - specifiers, designers, im- 
plementors, and maintained, They have some validity 
with respect to other agents - managers, users , customers , 
acceptance testers, etc, - participating in the develop- 
ment process, but the special concerns of these agents 
have not been given adequate attention here. 

Because of the quasi-research, quasi-development 
nature of the task of continuing the evolution of de- 
velopment environments, it would appear that the most 
success would result from university/industry or univer- 
sity/government collaborative efforts. Preliminary im- 
plementations and feasibility studies, tasks that 
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industry and government software development divisions 
frequently cannot devote time to carrying out, could be 
performed in university environments guided by the prac- 
tical experience of industry personnel. Production-ver- 
sion implementation and effectiveness assessment, tasks 
that university projects frequently lack the resources 
to adequately attack, could be performed In Industry or 
government with the guidance of university researchers, 
particularly with regard to the conduct and interpreta- 
tion of experiments. It would seem that the differing 
interests, experiences and capabilities of the various 
segments of the software engineering conmunity are not 
extensive or rich enough for any one segment alone to 
meaningfully attack tha overall problem; and it would 
seem that a collective effort would be effective and 
beneficial . 
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